The test snapshots getrawmempool() and then calls getrawtransaction()
on each txid.  In simple close both peers broadcast conflicting closer
txs: here l2's tx pays only 400sat fee (its entire 400sat balance goes
to fees since its own output is dust) while l1's pays 3375sat, so l1's
tx can RBF-replace l2's between the snapshot and the fetch.  The
getrawtransaction() call on the replaced txid then fails with error -5
(No such mempool or blockchain transaction).  A CI failure showed
exactly this ordering: l2 broadcast its closer tx, l1's higher-fee tx
replaced it 14ms later, and the test's per-txid fetch raced the
replacement.

Retry the whole snapshot-and-check loop when a txid vanishes
mid-iteration, keeping the single-output assertion hard.  This is the
same class of mempool race fixed for test_simple_close_delay_broadcast
in 5ae0705 ("tests: fix flaky test_simple_close_delay_broadcast
mempool race").

Changelog-None